<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head>
<title>NDIIPP Content Transfer Project: The BagIt File Packaging Format (V0.96)</title>
<meta http-equiv="Expires" content="Wed, 24 Jun 2009 09:41:45 +0000">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="description" content="The BagIt File Packaging Format (V0.96)">
<meta name="generator" content="xml2rfc v1.32 (http://xml.resource.org/)">
<style type="text/css"><!--
        body {
                font-family: verdana, charcoal, helvetica, arial, sans-serif;
                font-size: small; color: #000; background-color: #FFF;
                margin: 2em;
        }
        h1, h2, h3, h4, h5, h6 {
                font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
                font-weight: bold; font-style: normal;
        }
        h1 { color: #900; background-color: transparent; text-align: right; }
        h3 { color: #333; background-color: transparent; }

        td.RFCbug {
                font-size: x-small; text-decoration: none;
                width: 30px; height: 30px; padding-top: 2px;
                text-align: justify; vertical-align: middle;
                background-color: #000;
        }
        td.RFCbug span.RFC {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: bold; color: #666;
        }
        td.RFCbug span.hotText {
                font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: normal; text-align: center; color: #FFF;
        }

        table.TOCbug { width: 30px; height: 15px; }
        td.TOCbug {
                text-align: center; width: 30px; height: 15px;
                color: #FFF; background-color: #900;
        }
        td.TOCbug a {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
                font-weight: bold; font-size: x-small; text-decoration: none;
                color: #FFF; background-color: transparent;
        }

        td.header {
                font-family: arial, helvetica, sans-serif; font-size: x-small;
                vertical-align: top; width: 33%;
                color: #FFF; background-color: #666;
        }
        td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
        td.author-text { font-size: x-small; }

        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
        a.info {
                /* This is the key. */
                position: relative;
                z-index: 24;
                text-decoration: none;
        }
        a.info:hover {
                z-index: 25;
                color: #FFF; background-color: #900;
        }
        a.info span { display: none; }
        a.info:hover span.info {
                /* The span will display just on :hover state. */
                display: block;
                position: absolute;
                font-size: smaller;
                top: 2em; left: -5em; width: 15em;
                padding: 2px; border: 1px solid #333;
                color: #900; background-color: #EEE;
                text-align: left;
        }

        a { font-weight: bold; }
        a:link    { color: #900; background-color: transparent; }
        a:visited { color: #633; background-color: transparent; }
        a:active  { color: #633; background-color: transparent; }

        p { margin-left: 2em; margin-right: 2em; }
        p.copyright { font-size: x-small; }
        p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
        table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
        td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }

        ol.text { margin-left: 2em; margin-right: 2em; }
        ul.text { margin-left: 2em; margin-right: 2em; }
        li      { margin-left: 3em; }

        /* RFC-2629 <spanx>s and <artwork>s. */
        em     { font-style: italic; }
        strong { font-weight: bold; }
        dfn    { font-weight: bold; font-style: normal; }
        cite   { font-weight: normal; font-style: normal; }
        tt     { color: #036; }
        tt, pre, pre dfn, pre em, pre cite, pre span {
                font-family: "Courier New", Courier, monospace; font-size: small;
        }
        pre {
                text-align: left; padding: 4px;
                color: #000; background-color: #CCC;
        }
        pre dfn  { color: #900; }
        pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
        pre .key { color: #33C; font-weight: bold; }
        pre .id  { color: #900; }
        pre .str { color: #000; background-color: #CFF; }
        pre .val { color: #066; }
        pre .rep { color: #909; }
        pre .oth { color: #000; background-color: #FCF; }
        pre .err { background-color: #FCC; }

        /* RFC-2629 <texttable>s. */
        table.all, table.full, table.headers, table.none {
                font-size: small; text-align: center; border-width: 2px;
                vertical-align: top; border-collapse: collapse;
        }
        table.all, table.full { border-style: solid; border-color: black; }
        table.headers, table.none { border-style: none; }
        th {
                font-weight: bold; border-color: black;
                border-width: 2px 2px 3px 2px;
        }
        table.all th, table.full th { border-style: solid; }
        table.headers th { border-style: none none solid none; }
        table.none th { border-style: none; }
        table.all td {
                border-style: solid; border-color: #333;
                border-width: 1px 2px;
        }
        table.full td, table.headers td, table.none td { border-style: none; }

        hr { height: 1px; }
        hr.insert {
                width: 80%; border-style: none; border-width: 0;
                color: #CCC; background-color: #CCC;
        }
--></style>
</head><body>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tbody><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tbody><tr><td class="header">NDIIPP Content Transfer Project</td><td class="header">A. Boyko</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">Library of Congress</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">J. Kunze</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">California Digital Library</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">J. Littman</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">L. Madden</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">B. Vargas</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">Library of Congress</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">June 24, 2009</td></tr>
</tbody></table></td></tr></tbody></table>
<h1><br>The BagIt File Packaging Format (V0.96)</h1>

<h3>Abstract</h3>

<p>
This document specifies BagIt, a hierarchical file packaging format for
the exchange of generalized digital content.  A "bag" has just enough
structure to safely enclose descriptive "tags" and a "payload" but does
not require any knowledge of the payload's internal semantics.  This
BagIt format should be suitable for disk-based or network-based storage
and transfer.

</p><a name="toc"></a><br><hr>
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>&nbsp;
Introduction<br>
<a href="#anchor2">2.</a>&nbsp;
BagIt directory layout<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor3">2.1.</a>&nbsp;
Tag files<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor4">2.2.</a>&nbsp;
Declaration that this is a bag:  bagit.txt<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor5">2.3.</a>&nbsp;
Payload file manifest: manifest-&lt;algorithm&gt;.txt<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor6">2.4.</a>&nbsp;
Tag file manifest: tagmanifest-&lt;algorithm&gt;.txt<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor7">2.5.</a>&nbsp;
Example of a basic bag<br>
<a href="#anchor8">3.</a>&nbsp;
Valid bags and complete bags<br>
<a href="#anchor9">4.</a>&nbsp;
Other tag files<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor10">4.1.</a>&nbsp;
Completing a bag: fetch.txt<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor11">4.2.</a>&nbsp;
Other bag metadata: bag-info.txt<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor12">4.3.</a>&nbsp;
Another example bag<br>
<a href="#anchor13">5.</a>&nbsp;
Bag serialization<br>
<a href="#anchor14">6.</a>&nbsp;
Disk and network transfer<br>
<a href="#anchor15">7.</a>&nbsp;
Interoperability (non-normative)<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor16">7.1.</a>&nbsp;
Checksum tools<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor17">7.2.</a>&nbsp;
Windows and Unix file naming<br>
<a href="#anchor18">8.</a>&nbsp;
Security considerations<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor19">8.1.</a>&nbsp;
Special directory characters<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor20">8.2.</a>&nbsp;
Control of URLs in fetch.txt<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor21">8.3.</a>&nbsp;
File sizes in fetch.txt<br>
<a href="#anchor22">9.</a>&nbsp;
Acknowledgements<br>
<a href="#rfc.references1">10.</a>&nbsp;
References<br>
<a href="#anchor24">Appendix&nbsp;A.</a>&nbsp;
Change history<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor25">A.1.</a>&nbsp;
Changes from draft-03, 2009.04.11<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor26">A.2.</a>&nbsp;
Changes from draft-02, 2008.07.11<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor27">A.3.</a>&nbsp;
Changes from draft-01, 2008.05.30<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor28">A.4.</a>&nbsp;
Changes from draft-00, 2008.03.24<br>
<a href="#rfc.authors">§</a>&nbsp;
Authors' Addresses<br>
</p>
<br clear="all">

<a name="anchor1"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.1"></a><h3>1.&nbsp;
Introduction</h3>

<p>
BagIt is a hierarchical file packaging format designed to support
disk-based or network-based storage and transfer of generalized digital
content.  A bag consists of a "payload" and "tags".  The content of the payload
is the custodial focus of the bag and is treated as semantically opaque.
The "tags" are metadata files intended to facilitate and document the storage
and transfer of the bag.  The name, BagIt, is inspired by the "enclose and deposit" method
<a class="info" href="#ENCDEP">[ENCDEP]<span> (</span><span class="info">Tabata,
K., “A Collaboration Model between Archival Systems to Enhance the
Reliability of Preservation by an Enclose-and-Deposit Method,” 2005.</span><span>)</span></a>, sometimes referred to as "bag it and tag it".

</p>
<p>
Implementors of BagIt tools should consider interoperability
between different platforms, operating systems, toolsets, and languages.
In particular, differences in path separators, newline characters, reserved
file names, and maximum path lengths are all possible barriers to successfully
moving bags between different systems.  Discussion of these issues may be
found in the Interoperability section of this document.

</p>
<a name="anchor2"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.2"></a><h3>2.&nbsp;
BagIt directory layout</h3>

<p>
A "bag" consists of a base directory containing a set of top-level tag
files ("tags") and a single sub-directory named "data" that holds the
"payload".  The base directory may have any name.  The "data" directory
may contain an arbitrary file hierarchy.

</p>
<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>        &lt;base directory&gt;/
        |   manifest-&lt;algorithm&gt;.txt
        |   bagit.txt
        |   [optional additional tag files]
        \--- data/
              |   [optional file hierarchy]
</pre></div><p>


The tags consist of one or more files named
"manifest-<em>algorithm</em>.txt",
a file named "bagit.txt", and zero or more additional files.

</p>
<a name="anchor3"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.2.1"></a><h3>2.1.&nbsp;
Tag files</h3>

<p>
In top-level text files with a ".txt" extension, each line should be
terminated by a newline (LF), a carriage return (CR), or carriage return
plus newline (CRLF).  In all such tag files except "bagit.txt", text is
assumed to be encoded in the format specified in the "bagit.txt" file.

</p>
<a name="anchor4"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.2.2"></a><h3>2.2.&nbsp;
Declaration that this is a bag:  bagit.txt</h3>

<p>
The "bagit.txt" file should consist of exactly two lines,

</p>
<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>BagIt-Version: M.N
Tag-File-Character-Encoding: UTF-8
</pre></div><p>


where M.N identifies the BagIt major (M) and minor (N) version numbers,
and UTF-8 identifies the character set encoding of tag files.  The
"bagit.txt" file must be encoded in UTF-8 <a class="info" href="#RFC3629">[RFC3629]<span> (</span><span class="info">Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November&nbsp;2003.</span><span>)</span></a>.  The
appropriate version for a bag that conforms to this version of the
specification is "0.96".

</p>
<a name="anchor5"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.2.3"></a><h3>2.3.&nbsp;
Payload file manifest: manifest-&lt;algorithm&gt;.txt</h3>

<p>
A payload manifest is a tag file listing payload files and corresponding
checksums generated using a particular cryptographic checksum algorithm.
A payload manifest file has a name of the form 
manifest-<em>algorithm</em>.txt, where
<em>algorithm</em> is a string specifying a checksum
algorithm, such as

</p>
<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>manifest-md5.txt
manifest-sha1.txt
</pre></div><p>


Implementors of tools that create and validate bags are strongly
encouraged to support at least two widely implemented checksum
algorithms: "md5" <a class="info" href="#RFC1321">[RFC1321]<span> (</span><span class="info">Rivest, R., “The MD5 Message-Digest Algorithm,” April&nbsp;1992.</span><span>)</span></a>
and "sha1" <a class="info" href="#RFC3174">[RFC3174]<span> (</span><span class="info">Eastlake, D. and P. Jones, “US Secure Hash Algorithm 1 (SHA1),” September&nbsp;2001.</span><span>)</span></a>.
When using other algorithms, the name of the algorithm should be
normalized for use in the manifest's filename by lowercasing the
common name of the algorithm and removing all non-alphanumeric 
characters.

</p>
<p>
A bag may only contain a single payload manifest for a particular
checksum algorithm.

</p>
<p>
Each line of a payload manifest file has the form

</p>
<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>CHECKSUM FILENAME
</pre></div><p>


where FILENAME is the pathname of a file relative to the base directory
and CHECKSUM is a hex-encoded checksum calculated according to
<em>algorithm</em> over every octet in the file.
Only the slash character ('/') may be used as a path separator in
FILENAME.  One or more linear whitespace characters (spaces or tabs)
separate CHECKSUM from FILENAME.  There is no limitation on the length of
a pathname.  To facilitate bag interchange, implementors are encouraged
to read the Interoperability section.  As described below, if listed at
all, tag files should be listed in a tag manifest file, not in a payload
manifest file.

</p>
<p>
Payload manifests cannot account for empty directories because they only
include the pathnames of files.  To account for an empty directory, a bag
creator may wish to include at least one file in that directory; it
suffices, for example, to include a zero-length file named ".keep".

</p>
<a name="anchor6"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.2.4"></a><h3>2.4.&nbsp;
Tag file manifest: tagmanifest-&lt;algorithm&gt;.txt</h3>

<p>
A tag manifest is a tag file listing tag files and corresponding
checksums generated using a particular cryptographic checksum algorithm.
A tag manifest file has a name of the form
"tagmanifest-<em>algorithm</em>.txt", where
<em>algorithm</em> is a string specifying
a checksum algorithm.  For example, a tag manifest file using SHA1 would
have the name

</p>
<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>tagmanifest-sha1.txt
</pre></div><p>


</p>
<p>
A bag may only contain a single tag manifest for a particular
checksum algorithm.

</p>
<p>
A tag manifest file has the same form as the payload file manifest
file described earlier, but must not list any payload files.
As a result, no FILENAME listed in a tag manifest begins "data/".

</p>
<a name="anchor7"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.2.5"></a><h3>2.5.&nbsp;
Example of a basic bag</h3>

<p>
Here's a very simple bag containing an image and a companion OCR file.
Lines of file content are shown in parentheses beneath the file name.

</p>
<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>myfirstbag/
|
|   manifest-md5.txt
|    (49afbd86a1ca9f34b677a3f09655eae9 data/27613-h/images/q172.png)
|    (408ad21d50cef31da4df6d9ed81b01a7 data/27613-h/images/q172.txt)
|   tagmanifest-md5.txt
|    (27afbd86a1ca9f34b677a3f09655eaa4 manifest-md5.txt)
|    (59ad21d50cef31da4df6d9ed81b01b01 bagit.txt)
|
|   bagit.txt
|    (BagIt-version: 0.96)
|    (Tag-File-Character-Encoding: UTF-8)
|
\--- data/
     |
     |   27613-h/images/q172.png
     |    (... image bytes ...)
     |
     |   27613-h/images/q172.txt
     |    (... OCR text ...)
</pre></div><p>



</p>
<a name="anchor8"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3"></a><h3>3.&nbsp;
Valid bags and complete bags</h3>

<p>
A bag is considered <em>complete</em> if every file in
every payload manifest and tag manifest is present, and if every payload file
appears in at least one payload manifest.  A payload file does not need to
appear in every payload manifest as long as it appears in one payload manifest
(i.e., it must belong to the "union" of payload manifests).  In a complete bag
containing one or more tag manifests, any tag file may appear in zero or more 
of those manifests, but every tag file appearing in any tag manifest must be
present in the bag.

</p>
<p>
A bag is considered <em>valid</em>
if it is <em>complete</em>
and if each CHECKSUM in every payload manifest and tag manifest
can be verified against the contents of its corresponding FILENAME.

</p>
<p>
Note that tag files (including tag manifest files) can be added to or
removed from a bag without impacting the completeness or validity of the
bag as long as the tag files do not appear in a tag manifest.

</p>
<a name="anchor9"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.4"></a><h3>4.&nbsp;
Other tag files</h3>

<a name="anchor10"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.4.1"></a><h3>4.1.&nbsp;
Completing a bag: fetch.txt</h3>

<p>
For reasons of efficiency, a bag may be sent with a list of files to be
fetched and added to the payload before it can meaningfully be checked
for completeness.  An optional top-level file named "fetch.txt", if
present, contains such a list.  Each line of "fetch.txt" has the form

</p>
<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>URL LENGTH FILENAME
</pre></div><p>


where URL identifies the file to be fetched, LENGTH is the number of
octets in the file (or "-", to leave it unspecified), and FILENAME
identifies the corresponding payload file, relative to the base
directory.  Only the slash character ('/') may be used as a path
separator in FILENAME.  If FILENAME begins with a slash character, the
destination must still be treated as relative to the base directory.
One or more linear whitespace characters (spaces or tabs) separate these
three values, and any such characters in the URL must be percent-encoded
<a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January&nbsp;2005.</span><span>)</span></a>.  There is no limitation on the length of any
field in "fetch.txt".

</p>
<p>
The "fetch.txt" file allows a bag to be transmitted with
"holes" in it, which can be practical for several reasons.  For example,
it obviates the need for the sender to stage a large serialized copy of
the content while the bag is transferred to the receiver.  Also, this
method allows a sender to construct a bag from components that are either
a subset of logically related components (e.g., the localized logical
object could be much larger than what is intended for export) or
assembled from logically distributed sources (e.g., the object components
for export are not stored locally under one filesystem tree).

</p>
<a name="anchor11"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.4.2"></a><h3>4.2.&nbsp;
Other bag metadata: bag-info.txt</h3>

<p>
The "bag-info.txt" file is a tag file that contains metadata elements
describing the bag and the payload.  The metadata elements contained in the
"bag-info.txt" file are intended primarily for human readability.  All metadata
elements are optional.

</p>
<p>
A metadata element consists of a label, a colon, and a value.  Whitespace
after the first non-whitespace in the value is considered part of the
value.  Long values may be folded (continued) onto the next line by
inserting a newline (LF), a carriage return (CR), or carriage return plus
newline (CRLF) and indenting the next line (any combination of spaces and
tabs).  It is recommended that lines not exceed 79 characters in length.

</p>
<p>
Reserved metadata element names are case-insensitive and defined as follows.

</p>
<blockquote class="text"><dl>
<dt>Source-Organization</dt>
<dd>
    Organization transferring the content.

</dd>
<dt>Organization-Address</dt>
<dd>
    Mailing address of the organization.

</dd>
<dt>Contact-Name</dt>
<dd>
    Person at the source organization who is responsible for the content
    transfer.

</dd>
<dt>Contact-Phone</dt>
<dd>
    International format telephone number of person or position responsible.

</dd>
<dt>Contact-Email</dt>
<dd>
    Fully qualified email address of person or position responsible.

</dd>
<dt>External-Description</dt>
<dd>
    A brief explanation of the contents and provenance.

</dd>
<dt>Bagging-Date</dt>
<dd>
    Date (YYYY-MM-DD) that the content was prepared for delivery.

</dd>
<dt>External-Identifier</dt>
<dd>
    A sender-supplied identifier for the bag.

</dd>
<dt>Bag-Size</dt>
<dd>
    Size or approximate size of the bag being transferred, followed
    by an abbreviation such as MB (megabytes), GB, or TB; for example,
    42600 MB, 42.6 GB, or .043 TB.  Compared to Payload-Oxum (described
    next), Bag-Size is intended for human consumption.

</dd>
<dt>Payload-Oxum</dt>
<dd>
    The "octetstream sum" of the payload, namely, a two-part number
    of the form "OctetCount.StreamCount", where OctetCount is the
    total number of octets (8-bit bytes) across all payload file content
    and StreamCount is the total number of payload files.  Payload-Oxum
    is easy to compute (e.g., on Unix "wc -lc `find data/ -type f`")
    and should be included in "bag-info.txt" if at all
    possible.  Compared to Bag-Size (above), Payload-Oxum is
    intended for machine consumption.

</dd>
<dt>Bag-Group-Identifier</dt>
<dd>
    A sender-supplied identifier for the set, if any, of bags
    to which it logically belongs.
    This identifier must be unique across the sender's content, and if
    recognizable as belonging to a globally unique scheme, the receiver
    should make an effort to honor reference to it.

</dd>
<dt>Bag-Count</dt>
<dd>
    Two numbers separated by "of", in particular, "N of T",
    where T is the total number of bags in a group of bags and N is the
    ordinal number within the group; if T is not known, specify it as "?"
    (question mark).  Examples:  1 of 2, 4 of 4, 3 of ?, 89 of 145.

</dd>
<dt>Internal-Sender-Identifier</dt>
<dd>
    An alternate sender-specific identifier for the content
    and/or bag.

</dd>
<dt>Internal-Sender-Description</dt>
<dd>
    A sender-local prose description of the contents of the
    bag.

</dd>
</dl></blockquote>
<p>
In addition to these metadata elements, other arbitrary metadata elements
may also be present.

</p>
<p>
Here is an example "bag-info.txt" file.

</p>
<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>    Source-Organization: Spengler University
    Organization-Address: 1400 Elm St., Cupertino, California, 95014
    Contact-Name: Edna Janssen
    Contact-Phone: +1 408-555-1212
    Contact-Email: ej@spengler.edu
    External-Description: Uncompressed greyscale TIFF images from the
         Yoshimuri papers colle...
    Bagging-Date: 2008-01-15
    External-Identifier: spengler_yoshimuri_001
    Bag-Size: 260 GB
    Payload-Oxum: 279164409832.1198
    Bag-Group-Identifier: spengler_yoshimuri
    Bag-Count: 1 of 15
    Internal-Sender-Identifier: /storage/images/yoshimuri
    Internal-Sender-Description: Uncompressed greyscale TIFFs created
         from microfilm and are...
</pre></div><p>


</p>
<a name="anchor12"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.4.3"></a><h3>4.3.&nbsp;
Another example bag</h3>

<p>
The following example demonstrates a partially "holey" bag that includes a
"fetch.txt" file and a "bag-info.txt file".  As before, lines of file content are
shown in parentheses beneath the file name, with long lines continued
indented on subsequent lines.  This bag is not complete until every
file listed in the "fetch.txt" file is retrieved.

</p>
<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>mysecondbag/
|
|   manifest-md5.txt
|    (93c53193ef96732c76e00b3fdd8f9dd3 data/Collection Overview.txt)
|    (e9c5753d65b1ef5aeb281c0bb880c6c8 data/Seed List.txt)
|    (61c96810788283dc7be157b340e4eff4 data/gov-20060601-050019.arc.gz)
|    (55c7c80c6635d5a4c8fe76a940bf353e data/gov-20060601-100002.arc.gz)
|
|   fetch.txt
|    (http://foo.example.com/gov-06-2006/gov-20060601-050019.arc.gz
|        26583985 data/gov-20060601-050019.arc.gz)
|    (http://foo.example.com/gov-06-2006/gov-20060601-100002.arc.gz
|        99509720 data/gov-20060601-100002.arc.gz)
|
|   bag-info.txt
|    (Source-organization: California Digital Library)
|    (Organization-address: 415 20th St, 4th Floor, Oakland, CA  94612)
|    (Contact-name: A. E. Newman)
|    (Contact-phone: +1 510-555-1234)
|    (Contact-email: alfred@ucop.edu)
|    (External-Description: The collection "Local Davis Flood Control
|      Collection" includes captured California State and local
|      websites containing information on flood control resources for
|      the Davis and Sacramento area.  Sites were captured by UC Davis
|      curator Wrigley Spyder using the Web Archiving Service in
|      February 2007 and October 2007.)
|    (Bag-date: 2008.04.15)
|    (External-identifier: ark:/13030/fk4jm2bcp)
|    (Bag-size: about 22Gb)
|    (Payload-Oxum: 21836794142.4)
|    (Internal-sender-identifier: UCDL)
|    (Internal-sender-description: UC Davis Libraries)
|
|   bagit.txt
|    (BagIt-version: 0.96)
|    (Tag-File-Character-Encoding: UTF-8)
|
\--- data/
     |
     |   Collection Overview.txt
     |    (... narrative description ...)
     |
     |   Seed List.txt
     |    (... list of crawler starting point URLs ...)
</pre></div><p>



</p>
<a name="anchor13"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5"></a><h3>5.&nbsp;
Bag serialization</h3>

<p>
In some scenarios, it may be convenient to serialize the bag's base
directory (i.e., the filesystem hierarchy representing the bag) into a
single-file archive format such as TAR or ZIP (which might involve a
compression step).  The resulting
<em>serialization</em>
may later be deserialized (which might involve an uncompression step)
to recreate the filesystem hierarchy.  Several rules govern the
serialization of a bag and apply equally to all types of archive files:

</p>
<ol class="text">
<li>
One and only one bag appears in the top-level directory of a
serialization.

</li>
<li>
The serialization should have the same name as the bag's base directory,
but with an extension added to identify the format; for example, the
receiver of "mybag.tar.gz" expects the corresponding base directory
to be created as "mybag".

</li>
<li>
A bag is never serialized from within its base directory, but from the
parent of the base directory (where the base directory appears as an
entry).  Thus, after a bag is deserialized in an empty directory,
a listing of that directory shows exactly one entry.  For example,
deserializing "mybag.zip" in an empty directory causes the creation
of the base directory "mybag" and, beneath "mybag", the creation of
all payload and tag files.

</li>
<li>
One un-archiving (deserialization) step produces a single base directory
bag with the top-level structure as described in this document without
requiring an additional un-archiving step.  For example, after one
un-archiving step it would be an error for the "data/" directory to
appear as "data.tar.gz".  TAR and ZIP files may appear inside the payload
beneath the "data/" directory, where they would be treated as opaquely
as any other payload file or directory.

</li>
</ol>
<p>
When serializing a bag, care must be taken to
ensure that the format's restrictions on file naming, such as allowable
characters, length, or character encoding, will support the
requirements of the systems on which it will be used.  See the section on
Interoperability.

</p>
<a name="anchor14"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.6"></a><h3>6.&nbsp;
Disk and network transfer</h3>

<p>
When recording a bag on physical media (such as hard disk, CD-ROM, or 
DVD), the sender will need to select and format the media in a manner
compatible with both the content requirements (e.g., file names and
sizes) and the receiver's technical infrastructure.  If the receiver's
infrastructure is not known or the media needs to be compatible with a
range of potential receivers, consideration should be given to
portability and common usage.  For example, a "lowest common denominator"
for some content and potential receivers could be USB disk drives
formatted with the FAT32 filesystem.

</p>
<p>
During network-based transfer, while overall bag size is unlimited in
principle, it may be useful to split a large bag into several smaller
bags if there are practical constraints on the amount of bag data that
a receiver can stage at one time.

</p>
<p>
Transmitting a whole bag in serialized form as a single file will tend
to be the most straightforward mode of transfer.  When throughput is a
priority, use of "fetch.txt" lends itself to an easy, application-level
parallelism in which the list of URL-addressed items to fetch is divided
among multiple processes.
The mechanics of sending and receiving bags over networks is otherwise
out of scope of the present document and may be facilitated by protocols
such as <a class="info" href="#GRABIT">[GRABIT]<span> (</span><span class="info">NDIIPP/CDL, “The GrabIt File Exchange Protocol,” 2008.</span><span>)</span></a> and <a class="info" href="#SWORD">[SWORD]<span> (</span><span class="info">UKOLN/JISC CETIS, “Simple Web-service Offering Repository Deposit (SWORD),” 2008.</span><span>)</span></a>.

</p>
<a name="anchor15"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.7"></a><h3>7.&nbsp;
Interoperability (non-normative)</h3>

<p>
This section is not part of the BagIt specification.  It describes some
practical considerations for bag creators and receivers circa 2008.

</p>
<a name="anchor16"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.7.1"></a><h3>7.1.&nbsp;
Checksum tools</h3>

<p>
Some cautions regarding bag interchange arise in regard to the
commonly available checksum tools distributed with the GNU Coreutils
package (md5sum, sha1sum, etc.), collectively referred to here as
"md5sum".  First, md5sum can be run in binary or text
mode, where text mode sometimes normalizes line-endings.  While these
modes appear to produce the same checksums under Unix-like systems, they
can produce different checksums under Windows.  If using md5sum, it is
therefore safest run it in binary mode, with one caveat:  a side-effect
of binary mode is that md5sum requires a space and an asterisk ('*'),
compared to two spaces in text mode, between the CHECKSUM and FILENAME in
its manifest format.

</p>
<p>
Due to the widespread use of md5sum (and its relatives), it is not
unexpected for bag receivers to see manifests in which CHECKSUM and
FILENAME are separated by a space followed by an asterisk.  Implementors
creating or processing bags with md5sum should be aware of these subtle
differences, and ensure compliance with the manifest specification in this
document.  Implementors creating and processing bags with other tools may wish
to be tolerant of asterisks found in the manifests.

</p>
<p>A final note about md5sum-generated manifests is that for a
FILENAME containing a backslash ('\'), the manifest line will have a
backslash inserted in front of the CHECKSUM and, under Windows, the
backslashes inside FILENAME may be doubled.

</p>
<a name="anchor17"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.7.2"></a><h3>7.2.&nbsp;
Windows and Unix file naming</h3>

<p>
As mentioned previously, only the Unix-based path separator ('/') may be
used inside filenames listed in BagIt manifests and "fetch.txt" files.
When bags are exchanged between Windows and Unix platforms, care should
be taken to translate the path separator as needed.  Receivers of bags on
physical media should be prepared for filesystems created under either
Windows or Unix.  Besides the fundamental difference between path
separators ('\' and '/'), generally, Windows filesystems have more
limitations than Unix filesystems.  Windows path names have a maximum of
255 characters, and none of these characters may be used in a path
component:

</p>
<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>    &lt; &gt; : " / | ? *
</pre></div><p>


Windows also reserves the following names:  CON, PRN, AUX, NUL, COM1,
COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4,
LPT5, LPT6, LPT7, LPT8, and LPT9.  See <a class="info" href="#MSFNAM">[MSFNAM]<span> (</span><span class="info">Microsoft, “Naming a File,” 2008.</span><span>)</span></a> for more
information.

</p>
<a name="anchor18"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.8"></a><h3>8.&nbsp;
Security considerations</h3>

<a name="anchor19"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.8.1"></a><h3>8.1.&nbsp;
Special directory characters</h3>

<p>
The paths specified in the payload file manifest, tag file manfest, and
"fetch.txt" file do not prohibit special directory characters which might
be significant on implementing systems.  Implementors should take care
that files outside the bag directory structure are not accessed when
reading or writing files based on paths specified in a bag (cf Unix
chroot).

</p>
<p>
For example, path characters such as ".." or "~" in a maliciously crafted
"fetch.txt" file might cause a naive implementation to overwrite critical
system files.

</p>
<a name="anchor20"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.8.2"></a><h3>8.2.&nbsp;
Control of URLs in fetch.txt</h3>

<p>
Implementors of tools that complete bags by retrieving URLs listed in a
"fetch.txt" file need to be aware that some of those URLs may point to
hosts, intentionally or unintentionally, that are not under control of
the bag's sender. Checksums are not a guarantee against corruption and
spoofing in bag transfer. 

</p>
<a name="anchor21"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.8.3"></a><h3>8.3.&nbsp;
File sizes in fetch.txt</h3>

<p>
The size of a file, as optionally reported in the "fetch.txt" file,
cannot be guaranteed to match the actual size of the file to be
downloaded.  Implementors should not use the file size in "fetch.txt"
for critical resource allocation, such as buffer sizing or storage
requisitioning.

</p>
<a name="anchor22"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.9"></a><h3>9.&nbsp;
Acknowledgements</h3>

<p>
BagIt owes much to many thoughtful contributers and reviewers, including
Stephen Abrams, Mike Ashenfelder, Dan Chudnov, Brad Hards, Scott Fisher,
Keith Johnson, Erik Hetzner, Leslie Johnston, David Loy, Mark Phillips,
Tracy Seneca, Brian Tingle, Adam Turoff, and Jim Tuttle.

</p>
<a name="rfc.references1"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<h3>10.&nbsp;References</h3>
<table width="99%" border="0">
<tbody><tr><td class="author-text" valign="top"><a name="ENCDEP">[ENCDEP]</a></td>
<td class="author-text">Tabata, K., “<a href="http://www.iwaw.net/05/papers/iwaw05-tabata.pdf">A Collaboration Model between Archival Systems to Enhance
       the Reliability of Preservation by an Enclose-and-Deposit Method</a>,” 2005 (<a href="http://www.iwaw.net/05/papers/iwaw05-tabata.pdf">PDF</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="GRABIT">[GRABIT]</a></td>
<td class="author-text">NDIIPP/CDL, “<a href="http://dot.ucop.edu/home/jak/grabitspec.html">The GrabIt File Exchange Protocol</a>,” 2008 (<a href="http://dot.ucop.edu/home/jak/grabitspec.html">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="MSFNAM">[MSFNAM]</a></td>
<td class="author-text">Microsoft, “<a href="http://msdn2.microsoft.com/en-us/library/aa365247.aspx">Naming a File</a>,” 2008 (<a href="http://msdn2.microsoft.com/en-us/library/aa365247.aspx">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1321">[RFC1321]</a></td>
<td class="author-text"><a href="mailto:rivest@theory.lcs.mit.edu">Rivest, R.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc1321.txt">The MD5 Message-Digest Algorithm</a>,” RFC&nbsp;1321, April&nbsp;1992.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3174">[RFC3174]</a></td>
<td class="author-text">Eastlake, D. and P. Jones, “<a href="ftp://ftp.isi.edu/in-notes/rfc3174.txt">US Secure Hash Algorithm 1 (SHA1)</a>,” RFC&nbsp;3174, September&nbsp;2001.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3629">[RFC3629]</a></td>
<td class="author-text">Yergeau, F., “<a href="ftp://ftp.isi.edu/in-notes/rfc3629.txt">UTF-8, a transformation format of ISO 10646</a>,” STD&nbsp;63, RFC&nbsp;3629, November&nbsp;2003.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td>
<td class="author-text"><a href="mailto:timbl@w3.org">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com">Fielding, R.</a>, and <a href="mailto:LMM@acm.org">L. Masinter</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc3986.txt">Uniform Resource Identifier (URI): Generic Syntax</a>,” STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005 (<a href="ftp://ftp.isi.edu/in-notes/rfc3986.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc3986.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc3986.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="SWORD">[SWORD]</a></td>
<td class="author-text">UKOLN/JISC CETIS, “<a href="http://www.ukoln.ac.uk/repositories/digirep/index/SWORD">Simple Web-service Offering Repository Deposit (SWORD)</a>,” 2008 (<a href="http://www.ukoln.ac.uk/repositories/digirep/index/SWORD">HTML</a>).</td></tr>
</tbody></table>

<a name="anchor24"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.A"></a><h3>Appendix A.&nbsp;
Change history</h3>

<p>
(This appendix to be removed in the final draft.)

</p>
<a name="anchor25"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.A.1"></a><h3>A.1.&nbsp;
Changes from draft-03, 2009.04.11</h3>

<p>
Tweaked "tags" to leave as metaphor and added definition of the
previously undefined term, "tag file(s)".  Added implicit definition
of "serialization".  [Mental note:  the sentence, "Tag information
is optional." no longer appears in this spec.]  (John)

</p>
<p>
Re-worded interoperability statement in the Introduction.  (Justin)

</p>
<p>
Added statements regarding no limitations on various paths, URI, and other
lengths.

</p>
<p>
Clarified that the bag directory may not contain any other directories except
for the "data" directory.

</p>
<p>
A soel carriage return character is now explicitly allowed as a valid line
separator.

</p>
<p>
Tag file encoding requirements are now required to be as-stated in the
"bagit.txt".  The "bagit.txt" file is explicitly required to be in UTF-8.

</p>
<p>
Wording cleanup, clarifying payload file manifests and tag file manifests.

</p>
<p>
Tags in "bag-info.txt" no longer have any ordering requirement.

</p>
<p>
Tag formatting now explicitly states where significant whitespace begins
in the tag.

</p>
<p>
After some consideration, added some security considerations.

</p>
<p>
Made it clear that a bag may contain other bags, re: serialization.

</p>
<p>
Re-worded interoperabiilty to concerns to require creators to be
spec-compliant, and readers to be tolerant of known potential issues.

</p>
<p>
Specificity to the FILENAME element in "fetch.txt" is relative to the bag
root, and to make sure to treat leading slashes as relative.

</p>
<p>
Updated acknowledgements.

</p>
<p>
Various other minor edits for clarity and readibility.

</p>
<a name="anchor26"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.A.2"></a><h3>A.2.&nbsp;
Changes from draft-02, 2008.07.11</h3>

<p>
Added language to require the slash ('/') as path separator,
regardless of the platform where the bag was created.
Added an extra co-author and an Acknowledgements section.

</p>
<p>
Deleted the unnecessary "(optional)" from four of the metadata elements,
since all metadata elements are optional.  Softened the equivalence of
the serialization name and name of the contained bag base directory.
Replaced the reference to RFC2822 with an inline description of the
simpler bag-info.txt format.

</p>
<p>
Changed to a variable linear whitespace separator in the description
of manifest layout and in manifest examples.
Added two paragraphs under a new "Checksum tools" subsection of the
Interoperability section to describe some of the peculiarities of
dealing with the widely used GNU Coreutils checksum tools.

</p>
<p>
With the new version, 0.96, there is an important and incompatible change
of file name (package-info.txt -&gt; bag-info.txt), metadata element names
(Package-Size -&gt; Bag-Size, Packing-Date -&gt; Bagging-Date), and
descriptive language to replace the noun "package" with "bag" throughout
the spec.  This was to reduce unnecessary synonymy and free up the noun
"package" to name the physical container (e.g., a mailing carton) used to
transfer hard disks.

</p>
<p>
In section 7, another important change is the introduction of the
Payload-Oxum ("octetstream sum") metadata element to convey precise,
machine-readable payload size information for capacity planning
(especially useful when preparing to receive files listed in fetch.txt).
The Bag-size definition was adjusted to steer it more towards human
consumption.

</p>
<p>
In section 2.2 the spec now requires exactly two spaces between checksum
and filename in manifests.  This results from the experience that as of
2008, not all widely available validation tools are flexible in the
kind of separating whitespace recognized.  The examples have been
updated to include use the two-space form as well.

</p>
<p>
Comment added that while overall bag size is unlimited, practical
limitations on the amount of data that a receiver can stage may
warrant splitting a large bag into several smaller bags.

</p>
<p>
Added a reference to the SWORD protocol.

</p>
<p>
Minor edits for scanning and reformatting to cut down line length for
some figures that exceeded 72 chars (limit for Internet-Drafts).

</p>
<a name="anchor27"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.A.3"></a><h3>A.3.&nbsp;
Changes from draft-01, 2008.05.30</h3>

<p>
Added mention of preserving empty directories.

</p>
<p>
Simplified function of "tag checksum file" to "tag manifest", having same
format as payload manifest.  The tag manifest is optional and need not
include every tag file.

</p>
<p>
Loosened interpretation of payload manifest to "union" concept:
every payload file must be listed in at least one manifest but
need not be listed in every manifest.

</p>
<p>
Shortened the Introduction's first paragraph to be less duplicative
of text in the Abstract.

</p>
<p>
Changed Delivery-Date to Packing-Date.

</p>
<p>
Correctly sorted the author list and clarification of
deserialization wording.

</p>
<a name="anchor28"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.A.4"></a><h3>A.4.&nbsp;
Changes from draft-00, 2008.03.24</h3>

<p>
Author address corrections and miscellaneous stylistic edits.

</p>
<p>
Added some mention of physical media-based transfers, preferred
characteristics of transfer filesystems, and network transfer issues.

</p>
<p>
Added basic bag example early and changed the narrative to more clearly
delineate component files.

</p>
<p>
Wording changes under fetch.txt, and note that fetch.txt will need to be
modified before bag return.

</p>
<p>
Fixed checksum encoding reference to base64 rather than hex.  (B. Vargas)

</p>
<p>
Described simple normalization approach for checksum algorithm names. (B. Vargas)

</p>
<p>
In the example bag, add the ARC files found in the fetch.txt to the manifest as well (A. Turoff) 

</p>
<a name="rfc.authors"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tbody><tr><td class="author-text">&nbsp;</td>
<td class="author-text">Andy Boyko</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Library of Congress</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">101 Independence Avenue SE</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Washington, DC  20540</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:andy@boyko.net">andy@boyko.net</a></td></tr>
<tr cellpadding="3"><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">John A. Kunze</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">California Digital Library</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">415 20th St, 4th Floor</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Oakland, CA  94612</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">US</td></tr>
<tr><td class="author" align="right">Fax:&nbsp;</td>
<td class="author-text">+1 510-893-5212</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:jak@ucop.edu">jak@ucop.edu</a></td></tr>
<tr cellpadding="3"><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Justin Littman</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Library of Congress</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">101 Independence Avenue SE</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Washington, DC  20540</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Fax:&nbsp;</td>
<td class="author-text">+1 202-707-1957</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:jlit@loc.gov">jlit@loc.gov</a></td></tr>
<tr cellpadding="3"><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Liz Madden</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Library of Congress</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">101 Independence Avenue SE</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Washington, DC  20540</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Fax:&nbsp;</td>
<td class="author-text">+1 202-707-1957</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:emad@loc.gov">emad@loc.gov</a></td></tr>
<tr cellpadding="3"><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Brian Vargas</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Library of Congress</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">101 Independence Avenue SE</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Washington, DC  20540</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Fax:&nbsp;</td>
<td class="author-text">+1 202-707-1957</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:brian@ardvaark.net">brian@ardvaark.net</a></td></tr>
</tbody></table>
</body><script type="text/javascript"><!--
function __RP_Callback_Helper(str, strCallbackEvent, splitSize, func){var event = null;if (strCallbackEvent){event = document.createEvent('Events');event.initEvent(strCallbackEvent, true, true);}if (str && str.length > 0){var splitList = str.split('|');var strCompare = str;if (splitList.length == splitSize)strCompare = splitList[splitSize-1];var pluginList = document.plugins;for (var count = 0; count < pluginList.length; count++){var sSrc = '';if (pluginList[count] && pluginList[count].src)sSrc = pluginList[count].src;if (strCompare.length >= sSrc.length){if (strCompare.indexOf(sSrc) != -1){func(str, count, pluginList, splitList);break;}}}}if (strCallbackEvent)document.body.dispatchEvent(event);}function __RP_Coord_Callback(str){var func = function(str, index, pluginList, splitList){pluginList[index].__RP_Coord_Callback = str;pluginList[index].__RP_Coord_Callback_Left = splitList[0];pluginList[index].__RP_Coord_Callback_Top = splitList[1];pluginList[index].__RP_Coord_Callback_Right = splitList[2];pluginList[index].__RP_Coord_Callback_Bottom = splitList[3];};__RP_Callback_Helper(str, 'rp-js-coord-callback', 5, func);}function __RP_Url_Callback(str){var func = function(str, index, pluginList, splitList){pluginList[index].__RP_Url_Callback = str;pluginList[index].__RP_Url_Callback_Vid = splitList[0];pluginList[index].__RP_Url_Callback_Parent = splitList[1];};__RP_Callback_Helper(str, 'rp-js-url-callback', 3, func);}function __RP_TotalBytes_Callback(str){var func = function(str, index, pluginList, splitList){pluginList[index].__RP_TotalBytes_Callback = str;pluginList[index].__RP_TotalBytes_Callback_Bytes = splitList[0];};__RP_Callback_Helper(str, null, 2, func);}function __RP_Connection_Callback(str){var func = function(str, index, pluginList, splitList){pluginList[index].__RP_Connection_Callback = str;pluginList[index].__RP_Connection_Callback_Url = splitList[0];};__RP_Callback_Helper(str, null, 2, func);}
//--></script></html>